The present invention relates to the configuration of electronic entities such as microcircuit cards for example, also called “chip cards”, and relates more particularly to the pre-issuance and/or issuance steps implemented following fabrication of a microcircuit card.
Such microcircuit cards are used in many fields of application (telecommunications, banking applications . . . ). They can in particular allow their bearers to gain access to their bank accounts, to carry out payment transactions or even to authenticate themselves using a card reader.
FIG. 1 shows schematically the hardware architecture of a conventional microcircuit card 100.
More particularly, the microcircuit card 100 includes a microcontroller 102 comprising a processor 104, a read-only memory (or ROM) 106, a nonvolatile rewritable memory 108, an input/output port 110 and a volatile rewritable memory (or RAM) 112. The different elements of the microcontroller are interconnected by a bidirectional bus.
In the example considered here, the nonvolatile rewritable memory 108 is an EEPROM type memory.
In the first place, it is worth recalling that data are generally placed in the read-only memory 106 by the integrated circuit manufacturer during the manufacture of the microcontroller 102. Typically, the manufacturer writes appropriate data directly into the patterns of the memory layers of the ROM 106. These data include, for example the operating system OS of the microcontroller, as well as a boot script.
Further, in known fashion, once the manufacture of the microcircuit card 100 is finished, it is necessary to configure the card, that is to store so-called configuration data in the EEPROM memory 108 of the microcontroller 102 in order to make the card operational. The storage of these configuration data in the EEPROM memory 108 is carried out in two successive steps called pre-issuance and issuance.
A pre-issuance step consists of configuring the microcontroller 102 of the card 100 by storing various pre-issuance data in the EEPROM memory 108. Typically, this pre-issuance step makes it possible in particular:
to select, among the applications stored in advance in the read-only memory 106, those which will be active on the card 100 once it is operational. For example, in the field of banking applications, it is possible to activate a banking application of the Visa or MasterCard type. In the field of personal identification, it is also possible to configure the EEPROM memory so as to activate a “passport” or “driver's license” application;
to configure the selected application(s) (to select for example the protocol to be used: BAC, EAC . . . );
to select the speed at which the microcontroller 102 communicates with a compatible reader;
to select the operating speed of the processor 104;
to select the size limit of the EEPROM memory 108.
After the pre-issuance step, a step consisting of customizing, the card 100 is generally carried out. During this step, issuance data are stored in the EEPROM memory 108 of the microcontroller 102. issuance data consist of personal data of the final bearer of the card 100. They include for example at least one of the following data:                family name;        given name;        date of birth;        photo of the bearer,        card number,        cryptographic key of the card . . . .        
Most often, the issuance step includes in addition the creation of a file tree in the EEPROM memory 108.
Writing the pre-issuance, then the issuance data to the EEPROM memory 108 is accomplished by means of a microcircuit card reader. Typically, this card reader sends a succession of write commands to the microcontroller 102 during the pre-issuance and issuance steps. These commands contain data which the microcontroller 102 must write into the EEPROM memory 108.
Generally, these write commands are of the APDU (Application Protocol Data Unit) type complying with ISO standard 7816-4.
One of the principal APDU commands used during a pre-issuance step is the PUT DATA command.
Moreover, the principal APDU commands used during issuance are: CREATE FILE and UPDATE BINARY.
In a PUT DATA or UPDATE BINARY command, the data to be written are contained in the data field “Command Data Field” of the command. Likewise, in a CREATE FILE command, the file name (EFID per ISO 7816), the file size and the conditions for gaining access to the file in question are contained in the data field “Command Data Field” of the command.
Thus, the microcontroller 102 generally receives tens of APDU commands during the pre-issuance and issuance steps, each of these write commands requiring the writing of particular data (of a byte for example) to the EEPROM memory 108.
In general, the executable program of the read-only memory 106 implemented by the microcontroller 102 when an APDU command is received appears as follows:
S100: Checking whether authentication of the card reader by the card 100 has been successfully accomplished (implementation of the GET CHALLENGE and/or MUTUAL AUTH commands, for example . . . );
S110: Checking the authorization associated with the received APDU command, for example:
                S111. Checking that the current state of the card 100 allows the implementation of the received APDU command (the PUT DATA, CREATE FILE and UPDATE BINARY commands are generally only authorized in the card pre-issuance and/or issuance phases).        S112. Checking that, according to the authorization accomplished in step 100, the received APDU command can in fact be executed by the card.S120: Actual call of the APDU function received. This step can include in particular:        S121. Checking the integrity of the received APDU command. Typically, a signature of the APDU command is checked (MAC type signature, for example).        In general, to limit the execution time of this step, an identical session key is used for several APDU commands.        S122. Decrypting the configuration data to be written (to guarantee the confidentiality of the operation).        S123. Copying the data to be written into a memory buffer of the RAM memory 112 dedicated to writing to the EEPROM memory 108.        S124. Call to the driver of the EEPROM memory 108 to write the content of said memory buffer into the EEPROM memory 108.        
It should also be noted that, for each APDU command received, the microcontroller 102 must perform protocol processing (also called “protocol overhead”). This protocol processing includes, for example the checking by the microcontroller 102 of the CRC of a received APDU command.
Moreover, it is possible in some cases to proceed with a reconfiguration of the microcircuit card 100 after the issuance step, that is once the card is operational. Such a configuration corresponds to a post-issuance step, that is a configuration step subsequent to the issuance phase.
A post-issuance step makes it possible to modify the configuration of a microcircuit card in order, for example, to change the personal data or the directory and file tree in the card.
The Applicant, however, has observed that the configuration of a microcircuit card during the pre-issuance, issuance and post-issuance steps exhibits a major drawback in that it necessitates a particularly long execution time.
Indeed, as indicated above, for each APDU command received, the microcontroller 102 must perform a number of processing operations (authentication of the sender, encryption of the data to be written, verification of the integrity of the commands received, call to the write driver of the EEPROM memory 108 . . . ). Each of these operations requires a non-negligible execution time. Given the large number of APDU commands generally received by the microcontroller 102 during the pre-issuance and issuance steps, it is understandable that the configuration of the card 100 can be particularly costly in terms of time.
In practice, the manufacture of microcircuit cards is in fact subject to very strict time constraints during the micro card fabrication and configuration phases. Hence the greater the execution time required by the pre-issuance and issuance steps, the greater the cost of the microcircuit cards.
The Applicant has of course noted that it would be possible to increase the quantity of data contained in each APDU command sent to a card to be configured. However, increasing the data in the APDU command data field would considerably slow the processing to be carried out by the microcircuit card.